Not applicable
This present invention relates to an improvement in a communication system between computers and associated peripherals and appliances, and more particularly to platform- and protocol-independent communication.
In today""s industry many users are faced with severe incompatibility problems, when they need to establish an information processing system. It is because the users are able to choose from a large set of available system components from many vendors for performing similar functions. For example, a computer user may need to have access to printer, scanner, telephone, FAX, camera, microphone, audio system, machine tools, alarm system, monitoring system, or other similar device, system, or appliance, besides the computer, depending upon the intended purpose.
All such entities that reside outside the conventional boundary of a computer system, but are attached in some way and can communicate with it, are generally called computer peripherals. Lately, many types of such peripherals are commonly attached to one or more computers, all interconnected by means of a network. A pair of such entities, either connected directly or by means of a network, which have a special relationship wherein one requests a service to be performed while the other performs the requested service, are commonly referred to as Client-Server pair. A server may be another computer or a computer peripheral, as long as it is capable of performing a known service, for example printing or database-access, etc. A client is typically a user application (such as a wordprocessor), either running locally or remotely, that needs the service.
In such a situation, the request for service arises out of an application and travels through several layers of client system software, through the client hardware, through the connecting medium, through the server hardware, possibly through several layers of server system software, finally to the server application software. Likewise, the server response flows back to the client in identical manner but in the opposite direction.
Typically, many clients request service from a given server. A general case of such interaction occurs on a network, where many clients may be distributed over several computers. These clients may be user applications created by many separate vendors, which may be executing on computers created by many other and different vendors. Yet all these clients and servers must communicate reliably and efficiently. Therefore, a standard is needed for facilitating such communication between different entities. A network protocol is such a standard. A layered model, such as the OSI (Open Systems Interconnection), is a stack of network protocol software that a client-server pair typically uses today to communicate with each other.
Even though the above-described approach conceptually solves the compatibility problem between clients and servers on a network, incompatibility may result due to many factors in reality. To begin with, there are several protocols at the Data-Link layer itself each with its own unique properties and behavior (such as Ethernet/IEEE-802.3, Token-Ring/IEEE-803.4, AppleTalk, FDDI (Fiber Digital Data Interconnect), ATM (Asynchronous Transfer Mode), etc.). There are also several protocols at the Network and Transport layers as well, e.g. TCP/IP (Transmission Control Protocol/Internet Protocol), IPX/SPX (Novell standard), NETBEUI (Microsoft standard), and AppleTalk, to mention a few. Likewise, there are several protocols for communicating with directly attached servers too; e.g., RS-232, IEEE-1284, IEEE-1394, Apple Desktop Bus, etc.
It should be noted that although all these protocols facilitate communication successfully and reliably, all of these, with one exception, namely RPC (Remote Procedure Call), are designed to transport data. RPC is a layer designed to operate on top of TCP/IP for remote execution of programs and to interpret data in a specific manner regarding the execution of a program or application. The recipient is obligated to execute a pre-existing code contained thereat. RPC is directed at solving a particular problem with a particular motivation, namely distributed processing. It has been very successfully deployed in the implementation of NFS (Network File System) in UNIX systems. Lately, newer distributed program system architectures such as CORBA (Common Object Request Broker Architecture), DCOM/ActiveX (Distributed Common Object Model), SOM (Simple Object Model), NEST (Novel Embedded System Technology), and JAVA (developed by Sun Microsystem), and the like, have come into existence. However, all these are incompatible with each other, which results in extremely difficult inter-operation creating severe difficulties for the user.
This invention seeks to solve the problem of software incompatibility in the special case of client-server communication, especially with regard to that needed between an application running on a host computer and its computer peripherals intended to function as directly attached or network-connected servers. The existing solutions, as described above, are either too complex or too expensive for this purpose, since those are designed to solve a more general set of problems.
The client-server communication under consideration here is characterized by a simple exchange of data that can occur in a platform-independent manner. None of the above-described systems can accomplish this form of exchange as can the present invention. Nor can the inventions described in U.S. Pat No. 5,491,693 issued to Britton on Feb. 13, 1996 (addressing the problem of incompatibility between various communication protocols in a heterogeneous network environment and attempts to solve the problem through translation of communication data from one protocol to another using a smart Gateway); U.S. Pat. No. 5,613,090 issued to Willems on Mar. 18, 1997 (addressing the problem of a special case of disparate windowing environments, namely that existing between X-Window Systems available on various UNIX platforms, by introducing a layer of software in the communication path to translate request and responses in both directions); U.S. Pat. No. 5,627,829 issued to Gleeson on May 6, 1997 (addressing the problem of reducing network traffic by eliminating unnecessary protocol data which may arise out of transition between LANs and WANs); and U.S. Pat. No. 5,636,371 issued to Yu on Jun. 3, 1997 (addressing the problem of concurrent execution of multiple instances of well known port applications and solves it through port mapping on a single protocol stack).
In order to create a protocol-independent communication and hardware-independent software at both ends, the following principles must be upheld:
a. The exchange of information between the client and server must be in a format not tied to any communication protocol and be such that data contained in this exchange can be interpreted unambiguously in a vendor-neutral, hardware-neutral, and protocol-neutral manner.
b. The client should be required to know only the published capabilities (or parameters) of the server, along with possibly the number of parameters, their data-types (which must be most primitive and language-neutral), and their sizes. The knowledge of how a server may render those capabilities must be completely hidden from the client. Likewise, any client activity triggered by events reported by the server must be completely hidden from the server.
c. There is no need for either agent (client or server whether acting as initiator/requestor or responder/target) to indicate urgency or priority of requested action to the other. The agent performing the service has full knowledge of urgency or priority of requested action and it must keep that knowledge private.
If the above principles have to be adhered to, it is necessary to add an interface layer as a communication session manager (referred to herein as session manager or segue component) between the existing communication protocol (or transport mechanism) in use and the application software. The purpose of this segue component would be to create the abstractions needed for the desired independence and to be the exchange medium or facilitator of pre-formed containers or frames between the application (client""s or server""s) and the transport mechanism between client and server.
The foregoing has outlined some of the more pertinent objects of the present invention. These objects should be construed to be merely illustrative of some of the more prominent features and applications of the intended invention. Many other beneficial results can be attained by applying the disclosed invention in a different manner or by modifying the invention within the scope of the disclosure. Accordingly, other objects and a fuller understanding of the invention may be had by referring to the summary of the invention and the detailed description of the preferred embodiment in addition to the scope of the invention defined by the claims taken in conjunction with the accompanying drawings.
The above-noted problems, among others, are overcome by the present invention. Briefly stated, the present invention contemplates a unique segue component linked to one or more applications in a computer system and connected to a transport medium for transporting data between one or more clients of the computer system interconnected to one or more servers of the computer system wherein the component has a logical frame element for delivery to the applications and for collection of data representative of the operations associated with the applications; a physical frame element for delivery between a requesting agent and a target agent wherein the physical frame has a header element and an argument list element; means for converting data collected at the requesting agent""s logical frame into a literal form language-independent format and packaging that data in a byte-oriented format into the requesting agent""s physical frame; means for transporting the data to a target agent; means for extracting the data from the requesting agent""s physical frame into a target agent""s physical frame; and means for parsing that data, for converting it into executable form, and for delivering it to the target agent""s logical frame for action.
The foregoing has outlined the more pertinent and important features of the present invention in order that the detailed description of the invention that follows may be better understood so the present contributions to the art may be more fully appreciated. Additional features of the present invention will be described hereinafter which form the subject of the claims. It should be appreciated by those skilled in the art that the conception and the disclosed specific embodiment may be readily utilized as a basis for modifying or designing other structures and methods for carrying out the same purposes of the present invention. It also should be realized by those skilled in the art that such equivalent constructions and methods do not depart from the spirit and scope of the inventions as set forth in the appended claims.